Sprint 1
Autoevaluación de la entrega del Sprint 1
Al hacerse esta autoevaluación posteriormente a la entrega del Sprint 1, se van a considerar todas las condiciones de suspenso, incluyendo aquellas que no se pueden saber hasta el día después de la entrega (Condiciones de fallo de la presentación). En posteriores sprints, se evaluarán únicamente las condiciones de suspensión que se puedan evaluar en el momento de la entrega.
Condiciones de Suspenso del Equipo:
| Criterio | Descripción | Cumplimiento | Pass / Fail | Justificación |
|---|---|---|---|---|
| T-1) Aviso de Ausencia | Notificar previamente la ausencia de un miembro al inicio de la clase de evaluación | [x] Sí [ ] No | Pass | No ha faltado ningún miembro del grupo |
| T-2) Duración de la Presentación | Mantenerse dentro del tiempo estipulado para la presentación, sin excederse | [x] Sí [ ] No | Pass | La presentación ha durado el tiempo exigido sin exceder el límite |
| T-3) Finalización Anticipada | Concluir la presentación con diferencia menor a un minuto del tiempo designado | [x] Sí [ ] No | Pass | La presentación ha concluido 20 segundos antes del límite (Aproximadamente) |
| T-4) Divergencia en la Presentación | No presentar diferencias significativas entre la presentación realizada y la registrada en la plataforma de evaluación | [x] Sí [ ] No | Pass | La presentación entregada se correspondía a la presentada |
| T-5) Respuesta a Retroalimentación | Responder y actuar según la retroalimentación recibida durante la presentación, a menos que se proporcione una justificación explícita durante la misma | [x] Sí [ ] No | Pass | Bajo nuestro punto de vista, hemos sido uno de los grupos que más ha tenido en cuenta los aspectos de mejora mencionados por los profesores y por otros alumnos |
| T-6) Inclusión de Aspectos Esperados | Incluir en la presentación todos los aspectos esperados según lo discutido en clases previas | [x] Sí [ ] No | Pass | La presentación contaba con todos los apartados solicitados además de intentar utilizar alguna técnica de aprendizaje cómo es la gamificación para generar un personaje de lecciones aprendidas nombrado "AL". |
| T-7) Portada Adecuada | Presentar un documento con una portada adecuada que incluya todos los elementos requeridos | [x] Sí [ ] No | Pass | La portada cuenta con todos los elementos solicitados |
| T-8) Contenido del Documento de Contribuciones | Incluir todos los elementos requeridos en el documento de contribuciones a la Base de Conocimiento Compartida | [x] Sí [ ] No | Pass | Se añaden los cambios realizados a la base de gestión del conocimiento común |
| T-9) Correcta Entrega de Archivos | Realizar una entrega correcta sin errores en el formato o nombre de los archivos que conforman el entregable | [x] Sí [ ] No | Pass | De forma adicional, hemos entregado: - El enlace a nuestro docusaurus - Las demostraciones de cada prototipo - El registro de riesgos con el estado actual de cada riesgo - La replanificación de los sprints - El proceso de análisis y mejora de la calidad - El TCO detallado - La gestión de solicitudes de cambio |
| T-10) Cumplimiento de Instrucciones | Seguir las instrucciones establecidas en las pautas del revisor de software y evitar cualquier condición de suspensión relacionada con ellas | [] Sí [x] No | Fail | Ver en detalle |
| T-11) Evaluación del Rendimiento de Usuarios Piloto | Incluir la evaluación del rendimiento de los usuarios piloto en la entrega según el formato proporcionado | [ ] Sí [x] No | Fail | Ver en detalle |
Justificación de la Software-Reviewer-Guidelines
Guía del Revisor (RG)
| Criterio | Descripción | Cumplimiento | Pass / Fail | Justificación |
|---|---|---|---|---|
| Mapeo de Casos de Uso | Incluir un mapeo explícito desde los casos de uso hasta las interacciones en el software, detallando cómo realizar los casos de uso principales. | [x] Sí [ ] No | Pass | Se ha realizado un mapeo con cada uno de los casos de uso core definidos, además, se ha especificado que hay algunos que no actúan cómo deberían en comparación al producto final esperado. Principalmente hemos realizado todos los métodos de consulta, además de la parte visible de la interfaz de usuario. Lo que nos ha impedido realizar los métodos de creación ha sido la desconexión con el backend, aunque cómo se comentó en este sprint, se utilizó mockapi para poder continuar con el desarrollo (Siendo esto una solución temporal que nos ha permitido continuar con el desarrollo en frontend). |
| Datos Necesarios para la Revisión | Proporcionar datos necesarios para realizar la revisión, como URL de la página de inicio, credenciales de usuarios, URL del repositorio de GitHub, URL y credenciales de la plataforma de implementación, URL y credenciales de la herramienta de seguimiento, y enlaces a demostraciones mostradas en clases de evaluación. | [x] Sí [ ] No | Pass | Se añade todo lo solicitado |
| Requisitos Potenciales | Indicar requisitos potenciales para utilizar el sistema, como activación de ubicación u otros. | [x] Sí [ ] No | Pass | Además, en el docusaurus tenemos un apartado de casos de uso en los que se mencionan estos casos de uso y la ONG a la que aplica. |
Condiciones Suficientes para el Fracaso del Software
En este apartado, en caso de que NO sucedan fallos relacionados con el criterio, se marca que Sí en el cumplimiento.
| Criterio | Descripción | Cumplimiento | Pass / Fail | Justificación |
|---|---|---|---|---|
| Error HTTP Percibido por el Usuario | Una interacción legal con el sistema produce un error HTTP que es percibido por el usuario. | [x] Sí [ ] No | Pass | No hemos recibido ningún error de este tipo durante la revisión final del Sprint. |
| Pánico Percibido por el Usuario | Una interacción legal con el sistema provoca un pánico (crash, etc.) que es percibido por el usuario. | [x] Sí [ ] No | Pass | No se muestra ningún tipo de panic al usar la aplicación |
| Comportamiento No Esperado del Sistema | Una interacción legal con el sistema no produce el comportamiento esperado. | [] Sí [x] No | Fail | En este caso, nosotros al realizar la entrega nos cercioramos de que no hubiera ningún tipo de pantalla "vacía" que se producía cuando mockapi llegaba al límite de llamadas. Es posible que debido a que la revisión de este sprint ha sido posteriormente a la revisión por parte de los usuarios piloto, estos hayan llegado al límite de llamadas de mockapi y se haya visto reflejado en alguna parte del sistema. Aun así, puntuamos este criterio con 4 para penalizar por no haber notificado de la posibilidad de que esto sucediera |
| Falta de Detección de Datos Incorrectos | El sistema no detecta el envío de un formulario con datos incorrectos (validación de formularios). | [ ] Sí [x] No | Fail | No se pueden enviar formularios y, por consiguiente, no se pueden enviar datos incorrectos. Aun así, puntuamos este criterio con 4 para penalizar por la falta de la validación y envío de formularios. |
| Acceso no Autorizado a Datos | Un actor puede listar, editar o eliminar datos que pertenecen a otro actor. | [x] Sí [ ] No | Pass | No es posible realizar esta opción ya que todos los usuarios son administradores |
| Disponibilidad del Sistema en la Nube | El sistema no está desplegado en la nube o no está disponible en algún momento durante el período del proyecto (hasta julio). | [x] Sí [ ] No | Pass | Ambos sistemas están desplegados |
| Modificación/Actualización Post-Entrega | El despliegue del sistema es modificado o actualizado después de la fecha límite de entrega. | [x] Sí [ ] No | Pass | No se ha modificado el sistema desde su entrega |
Justificación del Pilot-Users-Performance-Evaluation
No se ha entregado debido a que los usuarios piloto no han revisado el servicio debido a que en todo momento nosotros consideramos que esto era algo opcional ya que, el prototipo a revisar no era funcional y no se podía probar. Por lo tanto, no se ha podido realizar la evaluación del rendimiento de los usuarios piloto. El motivo de que nosotros creyeramos de esta forma fue debido al contenido de la presentación de la planificación de la asignatura, que menciona el sprint 1 cómo un sprint orientado a los casos de uso core y al diseño de un plan de gestión de usuarios piloto (Adjunto imagen).
Resultado final: Fail
El resultado final indica un fallo. Uno de los requisitos fundamentales, en particular, fue el experimento con un baneo en MockAPI debido a alcanzar el límite máximo de peticiones diarias. Este incidente resultó en un fallo y provocó una respuesta inesperada en el sistema.